Skip to content

Conversation

@dcpleung
Copy link
Contributor

This sets the toolchain kconfig to allow generating FLIX instructions as it is disabled by default on Zephyr upstream.

This sets the toolchain kconfig to allow generating FLIX
instructions as it is disabled by default on Zephyr upstream.

Signed-off-by: Daniel Leung <[email protected]>
@dcpleung
Copy link
Contributor Author

@lgirdwood @kv2019i When updating to the latest Zephyr SHA, you will need the kconfig to restore the previous behavior of FLIX instruction generation.

@softwarecki
Copy link
Collaborator

I was misled by the Zephyrs PR title "cmake: toolchain/xt-clang: allow to skip FLIX generation". The title suggested adding an option to optionally disable FLIX generation, not changing the default behavior to disable it. The PR description explicitly states that:

FLIX generation is enabled by default. This lets the application developers to disable FLIX generation if needed.

Based on that, I expected an opt-out mechanism only, without altering the default state.

If FLIX needs to be disabled for sof application configuration, it should be done explicitly in the Linux overlay, without unnecessarily degrading performance or changing defaults for other platforms.


# Allow compiler to determine whether to generate FLIX instructions.
choice COMPILER_CODEGEN_VLIW
default COMPILER_CODEGEN_VLIW_AUTO if "$(ZEPHYR_TOOLCHAIN_VARIANT)" = "xt-clang"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

VLIW is a generic term which can be a project default (AUTO) state regardless of compiler, no need to specify xt-clang here

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure GCC cant emit VLIW for xtensa so it will need some check for Cadence compilers like above.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"AUTO" != "enabled", it means compiler will decide (use default config)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"AUTO" != "enabled", it means compiler will decide (use default config)

ok, so you are confirming no impact for GCC here and Zephyr SDK i.e. I just want to confirm we wont be passing any --enable-flix=auto type arguments to GCC which it wont understand if we remove the compiler check.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is only a configuration option, not a value passed to the compiler command line. The "auto" value does not result in setting any compile options.
https://github.com/zephyrproject-rtos/zephyr/blob/b4108b53f6d7ca8c1da596c7130318e64e26eaf0/CMakeLists.txt#L562-L568

Copy link
Member

@lgirdwood lgirdwood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM


# Allow compiler to determine whether to generate FLIX instructions.
choice COMPILER_CODEGEN_VLIW
default COMPILER_CODEGEN_VLIW_AUTO if "$(ZEPHYR_TOOLCHAIN_VARIANT)" = "xt-clang"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure GCC cant emit VLIW for xtensa so it will need some check for Cadence compilers like above.

@dcpleung
Copy link
Contributor Author

dcpleung commented Feb 2, 2026

The original idea was to add an option to disable it on demand. However, it turned out that FLIX was causing multiple CI failures so that needs to be disabled by default. Zephyr main should provide a stable foundation for others to build on. Hence this PR to re-enable it to keep the old behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants